Due to the 3rd generation network structure, applications within the UMTS Service Network can make use of core network functionality by means of open Application Program Interfaces (APIs). The open APIs, originally specified by the Parlay Group, are standardised within the 3rd Generation Partnership Project (3GPP) CN5 working group and the ETSI SPAN 12 group.
In the OSA architecture, the logical entities that implement the open APIs are called Service Capability Servers (SCSs). Additionally infrastructure APIs are specified called the Framework. Among other things, the Framework provides an API for registering an SCS, see Technical Specification Group Core Network, Open Service Access, Application Programming Interface, Part 3: Framework (Release 4), 3GPP Techn. Spec. 29.198-3 V4.1.0 (2001-06). See also ETSI ES 201 915-3 V0.0.4 (2001-06) Open Service Access; Application Programming Interface; Part 3: Framework.
Several ways of implementing the APIs in a network are thinkable. One way is to provide all API implementations within one physical network node (i.e., both the OSA Framework and SCS in the same node having protocols/interfaces to the various core network entities). This could be called a physical or single OSA gateway. A second way is a distributed approach. In this case, one node comprises central infrastructure software (Framework) and maybe a few SCS components, but the rest of the SCSs run on different nodes. Now, the OSA gateway is a logical gateway and API implementations can run on distributed nodes (i.e., SCSs). This means that the different entities provide their own APIs. This approach could be called logical or distributed OSA gateway.
Security in OSA is very important because applications can also be provided by other business domains than the network operator who provides the network capabilities. In practice, it might be that the network operator puts restrictions on the functionality of a certain SCS to be used by an application. What is allowed or not allowed, is defined by so-called Service Level Agreements (SLAs). A Service Level Agreement may consist of an off-line (e.g. by physically exchanging documents) and an on-line part. An application has to sign the on-line part of a service agreement before it is allowed to access any network service capability feature.
In P. Bhoj et al., SLA management in federated environments, Computer Networks, 35 (2001) page 5-24, an architecture is described that uses contracts based on service level agreements to share selective management information across administrative boundaries. The design of a prototype implementation for automatically measuring, monitoring, and verifying SLAs for Internet services is also described.
The physical or single node gateway approach has disadvantages from a performance point of view as all the communication has to go via the OSA gateway node. The distributed approach has disadvantages from a security point of view because applications need to get direct access to the network nodes. A big advantage of the latter approach is that no implementation of the SCS software at the central gateway node is necessary for introducing new SCSs. In case of a true physical gateway solution, of course for each new SCS new software has to be implemented on the gateway.